The SONAR-netCDF4 convention for sonar data, Version 1.1

Colophon

International Council for the Exploration of the Sea
Conseil International pour l’Exploration de la Mer

H. C. Andersens Boulevard 44-46
DK-1553 Copenhagen V
Denmark
Telephone (+45) 33 38 67 00
Telefax (+45) 33 93 42 15
www.ices.dk
info@ices.dk

Recommended format for purposes of citation:

Macaulay, G. and Peña, H. (Eds.). 2018. The SONAR-netCDF4 convention for sonar data, Version 1.0. ICES Cooperative Research Report No. 341. 33 pp. http://doi.org/10.17895/ices.pub.4392

Series Editor: Emory D. Anderson

The material in this report may be reused for non-commercial purposes using the recommended citation. ICES may only grant usage rights of information, data, images, graphs, etc. of which it has ownership. For other third-party material cited in this report, you must contact the original copyright holder for permission. For citation of datasets or use of data to be included in other databases, please refer to the latest ICES data policy on ICES website. All extracts must be acknowledged. For other reproduction requests please contact the General Secretary.

This document is the product of an expert group under the auspices of the International Council for the Exploration of the Sea and does not necessarily represent the view of the Council.

Cover image: © OCEANA/Carlos Suárez

http://doi.org/10.17895/ices.pub.4392
ISBN 978-87-7482-214-1
ISSN 1017-6195

Foreword

This report documents a convention for the storage of sonar data in netCDF4-formatted computer files, with an initial focus on omnisonars. The intention is to provide a well-founded convention that is supported by multiple sonar systems and multiple sonar analysis software packages, with the aim of facilitating the use of sonar data for research and survey purposes. The name of this convention is SONAR-netCDF4.

This document was developed by the Topic Group on Defining a data format for omnidirectional fisheries sonar, part of ICES Working Group on Fisheries Acoustics, Science, and Technology (WGFAST).

1. Introduction

Sonars have long been used to study and understand fisheries and the aquatic environment, but only recently have they directly provided digital data for quantitative analysis. Each manufacturer typically provides such data in a proprietary, but usually open, file format specific to their sonar systems. This hinders the effective use and exchange of such data by requiring the development and maintenance of file-reading software for multiple analysis programs and multiple sonars.

This document presents a convention for the storage and exchange of fisheries sonar data, with an initial focus on omnisonars. It is sufficiently generic and flexible to contain all foreseeable types of fisheries sonar data, along with necessary metadata. It also serves as a statement of the minimum set of data and metadata required to use omnisonar data in a quantitative manner.

1.1. Background

Many purpose-built file formats exist to store and exchange data from scientific and industrial equipment. Formats have been created by sonar and echosounder manufacturers; in addition, more generic acoustic data formats such as the Generic Water Column (GWC) format (Gee et al., 2012), the eXtended Triton Format (XTF; Triton (2013)), and the HydroACoustics (HAC) format (McQuinn et al., 2005) have also been created. These formats store a time-ordered sequence of datagrams, making it easy to append new data. Other data, such as geographical position, are typically interleaved into the sequence of datagrams. However, this is not optimal for analysis purposes when data are viewed and analysed as a set of pings and metadata from a time-period or spatial grouping. In addition, efficient random-read access to individual pings is not possible unless an index is available or created.

The Topic Group on Defining a data format for omnidirectional fisheries sonar do not want to create yet another sonar-specific file format; the knowledge required is not within the expertise of this group. However, the group does have the expertise to specify what data must be stored to allow for unambiguous use of backscatter data during quantitative analysis.

Accordingly, an existing file-format definition has been utilized and what should be stored is specified. The requirements for such a file format definition were:

ability to adequately represent the content and structure of sonar data and associated metadata;
standardized, open-file format;
fast random access to data stored in the file;
ability to store multiple types of data (e.g. position and backscatter);
ability to store metadata (e.g. sonar settings);
freely available and open libraries to read the data files into programming languages and technical computing environments (e.g. Java, C, C++, Python, Matlab, and R);
reliable and space-efficient format for data exchange and storage;
self-describing file format;
backwards compatibility upon modification of the file contents specification (i.e. old software/tools can still read relevant parts of a newer version);
computer platform-independent;
long-term support and extensive use in other scientific fields;
support for very large datasets.

Other scientific communities that collect and produce voluminous amounts of data have addressed similar needs, resulting in the Hierarchical Data Format (The HDF Group, 2017), currently at version 5 (HDF5). This is the only file format that meets all the listed requirements and is utilized for sonar data. There are two realizations of the HDF5 file format: (i) HDF5 itself and (ii) netCDF4 (Unidata, 2017), which is a subset of HDF5. Both are sufficient, but netCDF4 is more widely used and has slightly wider language support and implementation diversity. Accordingly, netCDF4 has been chosen.

Using a well-supported file format has the significant benefit that many data exploration, query, extraction, and analysis tools already read such files. This eliminates the need to develop and maintain sonar-specific file-reading software and facilitates the use of existing tools for data management, distribution, and analysis (a pertinent example is OPeNDAP, which provides a network-transparent standard for distributing scientific data).

An attractive feature of netCDF4 is the ease and transparency with which data can be added to an existing netCDF4 file. For example, processed data and how it was obtained can be included in the same file as the raw data. In addition, netCDF4 files can be very large while still providing fast access to data subsets. This allows a single SONAR-netCDF4 file to contain data from a transect or an entire survey. These features would simplify data management, improve traceability and long-term storage of analysis, enhance the sharing of processed datasets, and facilitate analysis of large disparate datasets. In general, any amount of additional data can be stored in the files without affecting the ability to use the data specified by the SONAR-netCDF4 convention.

A distinction is commonly made between file formats designed for archiving data in the original form, formats designed for storing partially or fully processed data, and formats for data exchange (Jackson et al., 2014). The SONAR-netCDF4 convention is intended to be suitable for all of these.

The initial focus of this convention has been to specify the storage of backscatter amplitude data from omnisonars. It is envisaged that future versions could specify how to store data from other acoustic equipment (e.g. echosounders) and derived data (e.g. bottom and school detections, categorization of backscatter, and integrated backscatter at multiple resolutions). Ancillary information such as sonar display screen-grabs could also be stored.

1.2. Versioning

This document and the convention that it describes will change over time to implement enhancements and to correct errors and omissions. To accommodate this, the SONAR-netCDF4 convention always requires a version number. This document has a separate version number, allowing for revised versions of the document to describe the same version of the convention.

The convention version number will always be included in the title of the document. The document version number will always be found in Chapter 7.

2. The recommended use of the SONAR-netCDF4 convention in post processing software

There are several processing steps that are common among the different postprocessing tools used by the community, and there is a growing need to use the different tools interchangeably. This chapter describes a few standard processing steps and outlines how the convention is intended to be used to facilitate the interchangeability. Note that the steps may be different between tools, and the convention only recommends how to store the data for the steps that are most common. We do not address how and in which order to process your data.

Exchange of information between different parts in the processing chain is becoming increasingly important. This is particularly relevant for emerging deep learning and machine learning frameworks, that have hardware requirements that are often different to the computers that are used for traditional desktop applications. Processing tools that run on autonomous platforms are also a need, which often require a different suite of software solutions, typically tailored to low power situations.

Typical steps in the postprocessing chain of marine sonar data consist of preprocessing and noise removal, bottom detection, classification, and integration (Figure 1). Here we outline the different groups in the convention that can support the input and output from these steps. If a processing software step can read the data, process the information and write back to the data using the convention, other software can pick it up and process it further.

Figure 1. Typical steps in a postprocessing chain for acoustical water column data. The two main groups may be used for several steps depending on the objective, and the GridGroup may be seen as a projection of the BeamGroup and the conversion to GridGroup is typically lossy. The output from the sonars are typically the BeamGroup and the report format are typically the GridGroup.

2.1. Typical processing steps and the associated data models

Two main data models are available in the convention: Beam_group and Grid_group. The Beam_group allows for different sample rates, different ping rates, etc, for each channel. It is a flexible model and able to cope with all echosounders and sonar systems. The Grid_group is a storage structure for multi-channel data that has been re-gridded or have a homogeneous ping times and range bins across the different frequencies.

Depending on the type of processing, both Beam_group and Grid_group could be used as input and output.

2.1.1. Denoising

2.1.2. Bottom detection

Bottom data is needed when integrating biological backscatter close to the sea bed. Different algorithms have been developed and the recommendation is to store the bottom depth in the Beam_group.

2.1.3. Labelling

Scrutinizing acoustic data, i.e. allocating the acoustic energy to categories, is traditionally achieved by manually assigning the backscatter. Both Beam_group and Grid_group support labels. An overview of how different software stores this information can be found here: Gavins label overview

2.1.4. Machine learning

Convolutional neural networks and other machine learning methods are suitable for processing sonar data, but it is typically more convenient to map the data to a common range, time and frequency grid before passinsg it into your preferred deep learning framework. The use of the Grid_group on a high resolution grid should be used for this purpose.

2.1.5. Integrated backscatter

The reports from the integration process typically goes into statistical paclages that can furhter process the data. It is recommended to use the Grid_group for this purpose, where the data is gridded typically on a coarser grid that that used for the machine learning objective

3. The SONAR-netCDF4 convention

3.1. Introduction

NetCDF4 is a data model, application programming interface (API) library, and file format for storing and managing data, developed and maintained by Unidata. Unidata is part of the US University Corporation for Atmospheric Research (UCAR) Community Programs (UCP) and funded primarily by the US National Science Foundation.

SONAR-netCDF4 is a data and metadata convention for the storage of data from active sonars in netCDF4 formatted files. SONAR-netCDF4 consists primarily of a naming convention and a data structure within the netCDF4 data model.

Datasets can be added to SONAR-netCDF4 files if they do not conflict with the SONAR-netCDF4 datasets. If such additions are potentially of use to other users of the file format, it is recommended that they be proposed for inclusion in this or additional convention specifications.

Each SONAR-netCDF4 file is intended to store data from one sonar mounted on one platform. The storage of data from multiple sonars and multiple platforms in one SONAR-netCDF4 file is not in the scope of the convention.

A design principle of SONAR-netCDF4 has been to focus on describing the acoustic backscatter data, not the overall purpose and context of why the data were collected. Such broader metadata are better stored in separate metadata systems and schema (e.g. ISO (2014); ICES (2016)).

3.2. Hierarchical structure

NetCDF4 has two main organizational concepts: (i) the variable, which can contain a variety of data structures, and (ii) groups, being a collection of variables. Groups and variables can have attributes attached to them. Groups can be arranged into a hierarchy.

SONAR-netCDF4 divides sonar data into seven netCDF4 groups:

Top-level – contains metadata about the SONAR-netCDF4 file format;
Annotation – contains time-stamped annotations;
Environment – contains information relevant to acoustic propagation through water;
Platform – contains information about the platform on which the sonar is installed;
Provenance – contains metadata about how the SONAR-netCDF4 version of the data were obtained;
Sonar – contains the backscatter and associated metadata; groups under Sonar are used for storing data from different sonar operating modes;
Vendor specific – contains vendor-specific information about the sonar and the data.

These groups contain variables and variable attributes with prescribed names and contents.

3.3. Obligations and missing data

Some variables and attributes in SONAR-netCD4 are mandatory; these form the minimal set of data required to quantitatively use backscattering amplitude data. The remaining variables and attributes have various levels of optionality and provide enhanced context and information about the sonar data. The obligations are:

M: mandatory
MA: mandatory if applicable or available
R: recommended
O: optional

Any non-mandatory variables can be absent from a SONAR-netCDF4 file. If a variable is mandatory, it must be present and must contain data. The set of mandatory variables and attributes has been chosen so that omnisonar systems can directly generate SONAR-netCDF4-conforming files without needing survey, experiment, or cruise-specific data.

The _FillValue attribute should be used to indicate missing data in variables. For floating point values, the IEEE 754 not-a-number (NaN) is the preferred fill value as this is convenient for commonly-used analysis packages (e.g. Python, Matlab, R).

3.4. Metadata and authorities

The fisheries acoustics community has developed a metadata convention for processed acoustic data (ICES, 2016). Where relevant, attribute and variable names have been reused from this convention. The NetCDF Climate and Forecast (CF) Metadata Conventions (Eaton et al., 2017) have been used where sensible (the efficient storage of unprocessed active sonar data has not been a design goal of the CF convention) along with the ESIP Attribute Convention for Data Discovery (ACDD). Terms and concepts from other metadata conventions have also been used where appropriate.

3.5. Units

All relevant variables and attributes in SONAR-netCDF4 files are required to have a textual netCDF4 attribute with the name “units” that specifies the units. The International System of Units (SI) is used. For simplicity, the data format mandates the use of particular units and their textual form, as per the definitions and conventions of the UDUNITS-2 package (UCAR, 2014). Decibels are commonly used in underwater acoustic quantities, but UDUNITS does not currently include such a unit. However, as the CF convention does permit decibel (with symbols: “dB”, “db”, and “dbel”), it is used in the SONAR-netCDF4 convention.

3.6. Datatypes

Each item has a suggested datatype, chosen to have sufficient range and precision to contain the expected data. Alternative datatypes can be used if necessary, but are discouraged. The “string” type should contain text in the UTF-8 encoding and should be treated as case-sensitive during any comparisons. Enumerated datatypes are used for some of the controlled vocabularies.

3.7. Vocabularies

The contents of some variables and attributes are restricted to defined vocabularies. These are listed or referenced where required. Desired additions to the vocabularies should be proposed to WGFAST for incorporation into this document. Some of the vocabularies have been represented as netCDF4 enumeration data types and some using the CF flag_values convention.

3.8. File-naming convention

SONAR-netCDF4 files should always end with a “.nc” suffix to indicate that they are a netCDF file. It is recommended that the filename should sort alphanumerically into chronological order (e.g. date and time of the first ping in the file; thus: YYYYMMDD-HHMMSS.nc). This facilitates file management and use in analysis systems.

3.9. CDL version of SONAR-netCDF4

An example of a SONAR-netCDF4 file is provided in the Common Data form Language (CDL). This provides a more formalized and structured representation of the data format. A CDL file can be converted into a NetCDF file using the “ncgen” utility (available as part of the netCDF software distribution) and then used as a template for creating populated SONAR-netCDF4 files.

3.10. Groups

3.10.1. Top-level group

The top-level group contains metadata about the SONAR-netCDF4 file, represented as attributes in the group (Table 1).

Table 1. Description of the top-level group.
Description	Obligation	Comment
Group attributes
:Conventions = "CF-1.7, SONAR-netCDF4-1.1, ACDD-1.3"	M	A comma-separated list of the conventions followed in the file. Include the SONAR-netCDF4 convention and version (e.g. ”SONAR-netCDF4-1.1”) and the relevant CF and ACDD conventions (e.g. ”CF-1.7” and ”ACDD-1.3”).
:date_created	M	Timestamp of file creation in ISO8601:2004 extended format, including the time zone (e.g. 2017-05-06T20:21:35Z).
:keywords	M	A comma-separated list of key words and/or phrases. For direct sonar-generated files, this should at least include the type of sonar.
:license	O	Either enter the URL to a standard or specific license, enter “Freely distributed” or “None”, or describe any restrictions to data access and distribution in free text.
:rights	O	Description of the usage rights of data in the file.
:sonar_convention_authority = "ICES"	M	Name of the organization managing and distributing the SONAR-netCDF4 convention. Currently ICES.
:sonar_convention_name = "SONAR-netCDF4"	M	Formal name of this convention (i.e. ”SONAR-netCDF4”).
:sonar_convention_version = "1.1"	M	SONAR-netCDF4 version number in the form “major.minor”, where major and minor are non-negative integers.
:summary	M	A paragraph describing the dataset, analogous to an abstract for a paper. For direct sonar-generated files, this can be blank.
:title	M	A short phrase or sentence describing the dataset. For direct sonar-generated files, this can be as simple as "Files generated by the XYZ sonar".

3.10.2. Annotation group

The annotation group contains timestamped annotations with optional identification code. Annotations are typically textual notes entered by users relevant to the data at a particular time. Some sonar systems provide an interface for creating manual and programmatic annotations. The netCDF4 group name is /Annotation and is described in Table 2.

Table 2. Description of the annotation group.
Description	Obligation	Comment
Dimensions
time = unlimited		Can be of fixed or unlimited length, as appropriate.
Coordinate variable
uint64 time(time)	MA
:axis = "T"
:calendar = "gregorian"
:long_name = "Timestamps of annotations"
:standard_name = "time"
:units = "nanoseconds since 1601-01-01 00:00:00Z"
Variables
string annotation_category(time)	O	Optional category for the annotation, for use in grouping annotation types.
:long_name = "Annotation category"
string annotation_text(time)	MA
:long_name = "Annotation text"

3.10.3. Environment group

The environment group contains information on environmental conditions, especially the speed of sound in water and acoustic absorption. The netCDF4 group name is /Environment and is described in Table 3. Sound speed, absorption, and current profiles can also be stored in this group, as can profile measurements of salinity, temperature, and pressure. Such profile data should use the NCEI NetCDF “profile” template, v2.0 or greater.

Table 3. Description of the environment group.
Description	Obligation	Comment
Dimensions
frequency = unlimited		Can be of fixed or unlimited length, as appropriate.
Coordinate variables
float frequency(frequency)	M
:long_name = "Acoustic frequency"
:standard_name = "sound_frequency"
:units = "Hz"
float :valid_min = 0.0
Variables
float absorption_indicative(frequency)	M	Indicative absorption values used to calculate the time-varied-gain (TVG), in the absence of more detailed data.
:long_name = "Indicative acoustic absorption"
:units = "dB/m"
float :valid_min = 0.0
float sound_speed_indicative	M	Mean sound speed in water used to calculate echo range, in the absence of more detailed sound-speed data.
:long_name = "Indicative sound speed"
:standard_name = "speed_of_sound_in_sea_water"
:units = "m/s"
float :valid_min = 0.0

3.10.4. Platform group

This group contains information about the sonar platform (e.g. ship). The netCDF4 group name is /Platform and is described in Table 4. Optionally, subgroups of /Platform can be used to store data from individual instruments that provide measurements about the platform, such as position, attitude, etc (note that if the measurements are about the environment around the platform they should be stored in the /Environment group). This structure must be used to store all instrument data.

Each platform can contain several instruments of the same type, such as multiple position sensors. Each instrument type is defined as a subgroup of the /Platform group and data for each instrument are stored in a subgroup of the instrument group. Subgroup names for common instrument types are given in Table 5 and how to store data from those instruments are also cross-referenced in Table 5. For example, data from individual position and attitude instruments are stored as subgroups of the /Platform/Position and /Platform/Attitude subgroups. The names of those subgroups must match the names of the instrument’s serial number or identifier as defined in the MRU_ids and position_ids variables in the /Platform group (Table 4). Additional instrument type subgroups can be created as required.

Each instrument group can also store unprocessed and unparsed sensor data. The data format for unprocessed and unparsed data is not prescribed, but could, for example, be NMEA-style text and/or numeric values. These subgroups must have one attribute called “description” that provides a short description of the contents. Other attributes can be added as desired. The variables under the subgroup should have appropriate names and an attribute that gives the units, where appropriate.

As a general example, parsed data from a GPS with id Garmin1234 would be stored in /Platform/Position/Garmin1234 and if NMEA data from that GPS were also stored, it would be in /Platform/Position/Garmin1234/NMEA.

The coordinate system convention used for the /Platform group variables is detailed in Chapter 5.

Table 4. Description of the platform group.
Description	Obligation	Comment
Group attributes
:platform_code_ICES	O	Platform code from the ICES SHIPC vocabulary (http://vocab.ices.dk/services/pox/GetCodeList/SHIPC).
:platform_name	O	Platform name of which the sonar is a part.
:platform_type	O	Platform type that the sonar is part of. Use the description field from the ICES ”Platform Class” vocabulary (http://vocab.ices.dk/services/pox/GetCodeList/Platform%20Class).
Types
byte enum transducer_type_t {receive_only = 0, transmit_only = 1, monostatic = 3 }		Transducer function - transmit only, receive only or both (monostatic)
Dimensions
transducer	M	Transducer count
position	M	position sensor count
MRU	M	MRU attitude sensor count
Variables
float MRU_offset_x(MRU)	R	x-axis component of the vector from the platform coordinate system origin to the motion reference unit origin.
:long_name = "Distance along the x-axis from the platform coordinate system origin to the motion reference unit sensor origin"
:units = "m"
float MRU_offset_y(MRU)	R	y-axis component of the vector from the platform coordinate system origin to the motion reference unit origin.
:long_name = "Distance along the y-axis from the platform coordinate system origin to the motion reference unit sensor origin"
:units = "m"
float MRU_offset_z(MRU)	R	z-axis component of the vector from the platform coordinate system origin to the motion reference unit origin.
:long_name = "Distance along the z-axis from the platform coordinate system origin to the motion reference unit sensor origin"
:units = "m"
float MRU_rotation_x(MRU)	R	Extrinsic angular rotation about the x-axis from the platform zero angle to the MRU zero angle.
:long_name = "Extrinsic rotation about the x-axis from the platform to MRU coordinate systems"
:units = "arc_degree"
float :valid_range = −180.0, 180.0
float MRU_rotation_y(MRU)	R	Extrinsic angular rotation about the y-axis from the platform zero angle to the MRU zero angle.
:long_name = "Extrinsic rotation about the y-axis from the platform to MRU coordinate systems"
:units = "arc_degree"
float :valid_range = −180.0, 180.0
float MRU_rotation_z(MRU)	R	Extrinsic angular rotation about the z-axis from the platform zero angle to the MRU zero angle.
:long_name = "Extrinsic rotation about the z-axis from the platform to MRU coordinate systems"
:units = "arc_degree"
float :valid_range = −180.0, 180.0
string MRU_ids(MRU)	MA	MRU serial number or identification name. Must be a valid netCDF4 group name.
string position_ids(position)	MA	Position sensor serial number or identification name. Must be a valid netCDF4 group name.
float position_offset_x(position)	R	Distance from the platform coordinate system origin to the latitude/longitude position origin along the x-axis.
:long_name = "Distance along the x-axis from the platform coordinate system origin to the latitude/longitude sensor origin"
:units = "m"
float position_offset_y(position)	R	Distance from the platform coordinate system origin to the latitude/longitude position origin along the y-axis.
:long_name = "Distance along the y-axis from the platform coordinate system origin to the latitude/longitude sensor origin"
:units = "m"
float position_offset_z(position)	R	Distance from the platform coordinate system origin to the latitude/longitude position origin along the z-axis.
:long_name = "Distance along the z-axis from the platform coordinate system origin to the latitude/longitude sensor origin"
:units = "m"
float transducer_offset_x(transducer)	R	Distance from the platform coordinate system origin to the transducer along the x-axis.
:long_name = "x-axis distance from the platform coordinate system origin to the sonar transducer"
:units = "m"
float transducer_offset_y(transducer)	R	Distance from the platform coordinate system origin to the transducer along the y-axis.
:long_name = "y-axis distance from the platform coordinate system origin to the sonar transducer"
:units = "m"
float transducer_offset_z(transducer)	R	Distance from the platform coordinate system origin to the transducer along the z-axis.
:long_name = "z-axis distance from the platform coordinate system origin to the sonar transducer"
:units = "m"
string transducer_ids(transducer)	MA	Transducer serial number or identification name
float transducer_rotation_x(transducer)	R	Extrinsic angular rotation about the x-axis from the transducer zero angle to the coordinate system origin zero angle.
float :valid_range = −180.0, 180.0
:units = "arc_degree"
:long_name = "Extrinsic rotation about the x-axis from the transducer to reference coordinate systems"
float transducer_rotation_y(transducer)	R	Extrinsic angular rotation about the y-axis from the transducer zero angle to the coordinate system origin zero angle.
float :valid_range = −180.0, 180.0
:units = "arc_degree"
:long_name = "Extrinsic rotation about the y-axis from the transducer to reference coordinate systems"
float transducer_rotation_z(transducer)	R	Extrinsic angular rotation about the z-axis from the transducer zero angle to the coordinate system origin zero angle.
float :valid_range = −180.0, 180.0
:units = "arc_degree"
:long_name = "Extrinsic rotation about the z-azis from the transducer to reference coordinate systems"
transducer_type_t transducer_function(transducer)	M	The transducer function (that is, transmit_only, receive_only, or monostatic)
:long_name = "Transducer function (transmit_only, receive_only, monostatic)"
float water_level	R	Distance from the origin of the platform coordinate system to the nominal water level measured along the z-axis of the platform coordinate system (positive values are below the origin). The distance between the nominal and actual water level is provided by vertical_offset.
:long_name = "Distance from the platform coordinate system origin to the nominal water level along the z-axis"
:units = "m"
Subgroups
Positions	M	Suggested subgroup to store Position sensor data.
Attitudes	M	Suggested subgroup to store MRU sensor data.

Table 5. Suggested subgroup names for platform instruments.
Sensor or datagram	Subgroup name	Comment
Attitude sensors, MRU	Attitude	Use data structure described in Table 6
GPS sensors, Position	Position	Use data structure described in Table 7
Clock or time synchronisation datagrams	Clock
NMEA telegrams	NMEA	Use data structure described in Table 8.

Table 6. Description of a platform attitude subgroup.
Description	Obligation	Comment
Group attributes
string :description	O	System description
Dimensions
time		can be fixed or unlimited length, as appropriate
Coordinate variables
uint64 time(time)	M	Time from attitude sensor
:axis = "T"
:calendar = "gregorian"
:long_name = "Timestamps for attitude data"
:standard_name = "time"
:units = "nanoseconds since 1601-01-01 00:00:00Z"
Variables
float heading(time)	MA	Platform heading. Measured clockwise from north.
:long_name = "Platform heading(true)"
:standard_name = "platform_orientation"
:units = "degrees_north"
float :valid_range = 0.0, 360.0
float heading_rate(time)	MA	Platform heading rate.
:long_name = "Platform heading rate"
:units = "degree/s"
float pitch(time)	M	Platform pitch. Positive values indicate a bow-up pitch.
:standard_name = "platform_pitch_angle"
:units = "arc_degree"
:long_name = "pitch angle"
float :valid_range = −90.0, 90.0
float pitch_rate(time)	O	Platform pitch rate
:standard_name = "platform_pitch_rate"
:units = "degree/s"
:long_name = "pitch rate"
float roll(time)	M	Platform roll. Positive values indicate a roll to starboard.
:standard_name = "platform_roll_angle"
:units = "arc_degree"
:long_name = "roll angle"
float roll_rate(time)	O	Platform roll rate
:standard_name = "platform_roll_rate"
:units = "degree/s"
:long_name = "roll rate"
float vertical_offset(time)	M	Distance from the nominal water level to the actual water level measured along the _z_axis of the platform coordinate system (positive values are when the actual water level is below the nominal water level). For ships and similar, this is called heave, but the concept applies equally well to underwater vehicle depth.This offset is applied at the position given by (MRU_offset_x, MRU_offset_y, MRU_offset_z).
:units = "m"
:long_name = "Platform vertical offset from nominal"
Subgroups
NMEA	O	Suggested subgroup to store raw NMEA data.

Table 7. Description of a platform position subgroup.
Description	Obligation	Comment
Group attributes
string :description	O	System description
Dimensions
time		can be fixed or unlimited length, as appropriate
Coordinate variables
uint64 time(time)	M	Time from position sensor
:axis = "T"
:calendar = "gregorian"
:long_name = "Timestamps for position data"
:standard_name = "time"
:units = "nanoseconds since 1601-01-01 00:00:00Z"
:coordinates = "time latitude longitude"
Variables
double latitude(time)	M	Latitude of the platform reference point in WGS-84 reference system
double :valid_range = −90.0, 90.0
:standard_name = "Platform latitude"
:units = "degrees_north"
:long_name = "latitude"
:coordinates = "time latitude longitude"
double :_FillValue = Double.NaN
double longitude(time)	M	Longitude of the platform reference point in WGS-84 reference system
double :valid_range = −180.0, 180.0
:standard_name = "Platform longitude"
:units = "degrees_east"
:long_name = "longitude"
:coordinates = "time latitude longitude"
double :_FillValue = Double.NaN
float heading(time)	MA	Heading refers to the direction a platform is pointing. This may or may not be the direction that the platform actually travels, which is known as its course or track. Any difference between course and heading is due to the motion of the underlying medium, the air or water, or other effects like skidding or slipping. Heading is typically based on compass directions, so 0° (or 360°) indicates a direction toward true North, 90° indicates a direction toward true East, 180° is true South, and 270° is true West.
:standard_name = "platform_orientation"
:units = "degree"
:long_name = "Platform heading(true)"
:coordinates = "time latitude longitude"
float course_over_ground(time)	O	a platform course is the cardinal direction along which the platform is to be steered
:standard_name = "platform_course"
:units = "m/s"
:long_name = "degree"
:coordinates = "time latitude longitude"
float speed_over_ground(time)	MA	Speed is the magnitude of velocity. The platform speed with respect to ground is relative to the solid Earth beneath it, i.e. the sea floor for a ship.
:standard_name = "platform_speed_wrt_ground"
:units = "m/s"
:long_name = "speed_over_ground"
float :valid_min = 0.0
:coordinates = "time latitude longitude"
float speed_relative(time)	MA	Platform speed relative to water.
:long_name = "Platform speed relative to water"
:standard_name = "platform_speed_wrt_seawater"
:units = "m/s"
float :valid_min = 0.0
:coordinates = "time latitude longitude"
float height_above_reference_ellipsoid(time)	MA	Height of the platform reference point above the WGS-84 ellipsoid
:standard_name = "height_above_reference_ellipsoid"
:units = "m"
:long_name = "height_above_reference_ellipsoid"
:coordinates = "time latitude longitude"
float altitude(time)	MA	Altitude is the (geometric) height of the platform reference point above the reference WGS-84 geoid. The geoid is similar to mean sea level.
:standard_name = "altitude"
:units = "m"
:long_name = "altitude"
:coordinates = "time latitude longitude"
float distance(time)	O	Distance travelled by the platform from an arbitrary location.
:long_name = "Distance travelled by the platform"
:units = "m"
float :valid_min = 0.0
:coordinates = "time latitude longitude"
Subgroups
NMEA	O	Suggested subgroup to store raw NMEA data.

Table 8. Suggested group for storing NMEA datagrams from marine instruments.
Description	Obligation	Comment
Group attributes
:description = "All NMEA sensor datagrams"	M	Description of the subgroup contents.
Dimensions
time = unlimited		Can be of fixed or unlimited length, as appropriate.
Coordinate variables
uint64 time(time)	M
:axis = "T"
:calendar = "gregorian"
:long_name = "Timestamps for NMEA datagrams"
:standard_name = "time"
:units = "nanoseconds since 1601-01-01 00:00:00Z"
Variables
string NMEA_datagram(time)	O	Example of how to store NMEA datagrams.
:long_name = "NMEA datagram"

3.10.5. Provenance group

The provenance group provides information on how the SONAR-netCDF4 version of the data were created. The netCDF4 group name is /Provenance and is described in Table 9.

Table 9. Description of the provenance group.
Description	Obligation	Comment
Group attributes
:conversion_software_name	MA	Name of the software used to do the conversion.
:conversion_software_version	MA	Version of the software used to do the conversion.
:conversion_time	MA	Date and time of the start of the conversion process in extended ISO8601:2005 extended format, including time zone.
Dimensions
filenames = unlimited		Can be of fixed or unlimited length, as appropriate.
Variables
string source_filenames(filenames)	MA	Vector of datafile names that were used to generate the data in this SONAR-netCDF4 file.
:long_name = "Source filenames"

3.10.6. Sonar group

This group contains the sonar backscatter data and associated metadata. The netCDF4 group name is /Sonar and is described in Table 10.

Data from each beam mode (e.g. horizontal and vertical beam modes) are stored in subgroups under the /Sonar group (see Table 11). The form of the backscatter data can vary between different sonar systems. For example, some provide a complex-valued amplitude, while others provide a real- or integer-valued amplitude. Variable definitions for data from split-aperture systems are not currently specified.

Subgroups under /Sonar each have a coordinate variable that contains ping timestamps. In some cases the coordinate variables in different subgroups contain the same data (such as when a sonar produces several types of beam data from each and every ping). To avoid duplication of timestamp data, a coordinate variable can be used across multiple subgroups. For organisational reasons, it is then recommended that such coordinate variables be located in the /Sonar group.

Table 10. Description of the sonar group.
Description	Obligation	Comment
Group attributes
:sonar_manufacturer	R	Name of the sonar manufacturer.
:sonar_model	R	Name of the sonar model.
:sonar_serial_number	R	Sonar serial number.
:sonar_software_name	R	Sonar software name.
:sonar_software_version	R	Sonar software version.
:sonar_type = "omni-sonar"	M	Type of sonar, chosen from a defined vocabulary (currently only one value): ”omnisonar” (a sonar with a nominally omnidirectional mode).
Types
byte enum beam_stabilisation_t {not_stabilised = 0, stabilised = 1}		Whether or not the beam direction is compensated for platform motion.
byte enum beam_t {single = 0, split_aperture_angles = 1, split_aperture_4_subbeams = 2, split_aperture_3_subbeams = 3, split_aperture_3_1_subbeams = 4}		Beam type. Split aperture indicates a beam that can detect the arrival angle of echoes, while single beam cannot.
byte enum conversion_equation_t {type_1 = 1, type_2 = 2, type_3 = 3, type_4 = 4}		The type of equation used to convert backscatter measurements into volume backscattering and target strength.
byte enum transmit_t {CW = 0, LFM = 1, HFM = 2}		Type of transmit pulse. CW = continuous wave – a pulse nominally of one frequency, LFM = linear frequency modulation – a pulse which varies from transmit_frequency_start to transmit_frequency_stop in a linear manner over the nominal pulse duration (transmit_duration_nominal), HFM = hyperbolic frequency modulation – a pulse which varies from transmit_frequency_start to transmit_frequency_stop in a hyperbolic manner over the nominal pulse duration (transmit_duration_nominal).
float(*) sample_t		Variable length vector used to store ragged arrays of backscatter data. Data type can be varied to suit data storage needs.
float(*) angle_t		Variable length vector used to store ragged arrays of split-aperture angles. Data type can varied to suit data storage needs.
Subgroups
Beam_group1	M	Example of a beam group. Include as many subgroups as necessary for different beam groups. Use unique group names, preferably of the form Beam_groupX where X is an integer.

Table 11. Description of the beam mode subgroups of the sonar group.
Description	Obligation	Comment
Group attributes
:beam_mode	M	Mode of the beam in this subgroup, taken from the defined vocabulary of: “vertical” (a set of beams that form a vertical slice through the water), ”horizontal” (a set of beams that form a nominally horizontal plane through the water), and ”inspection” (a set of beams with arbitrary pointing directions).
conversion_equation_t :conversion_equation_type	M	Type of equation used to convert backscatter measurements into volume backscattering strength and target strength.
int :preferred_MRU	MA	Index of the MRU sensor to use by default. If the sensor used can be dynamically changed, refer to the variable active_MRU. Index matches the ones used in the Platform MRU sensors variables.
int :preferred_position	MA	Index of the position sensor to use by default. If the sensor used can be dynamically changed, refer to the variable active_position_sensor. Index matches the ones used in the Platform position sensors variables.
Dimensions
beam		The number of beams in this beam group.
subbeam		The number of sub-beams in these beams.
ping_time = unlimited		Can be of fixed or unlimited length, as appropriate.
tx_beam		The number of transmit beams in this beam group
Coordinate variables
string beam(beam)	M	Beam name (or number or identification code).
:long_name = "Beam name"
uint64 ping_time(ping_time)	M	Timestamp at which each ping occurred.
:axis = "T"
:calendar = "gregorian"
:long_name = "Time-stamp of each ping"
:standard_name = "time"
:units = "nanoseconds since 1601-01-01 00:00:00Z"
:coordinates = "ping_time platform_latitude platform_longitude"
Variables
sample_t backscatter_i(ping_time, beam, subbeam)	MA	Imaginary part of backscatter measurements. Each element in the 3D matrix is a variable length vector (of type sample_t) that contains the samples for that beam, ping time, and optionally subbeam.
:long_name = "Raw backscatter measurements (imaginary part)"
:units = "as appropriate"		Use units appropriate for the data.
sample_t backscatter_r(ping_time, beam, subbeam)	M	Real part or amplitude or power of backscatter measurements. Each element in the 3D matrix is a variable length vector (of type sample_t) that contains the samples for that beam, ping time, and optionally subbeam.
:long_name = "Raw backscatter measurements (real part)"
:units = "as appropriate"		Use units appropriate for the data.
angle_t echoangle_major(ping_time, beam)	MA	Electrical phase angle of the incoming echoes at time ping_time relative to the direction of each beam. Only required if the beam_type variable for this ping_time is set to split_aperture_angles.
:long_name = "Echo arrival angle in the major beam coordinate"
:units = "arc_degree"
float :valid_range = −180.0, 180.0
angle_t echoangle_minor(ping_time, beam)	MA	Electrical phase angle of the incoming echoes at time ping_time relative to the direction of each beam. Only required if the beam_type variable for this ping_time is set to split_aperture_angles.
:long_name = "Echo arrival angle in the minor beam coordinate"
:units = "arc_degree"
float :valid_range = −180.0, 180.0
float echoangle_major_sensitivity(beam)	MA	Scaling factor to convert electrical arrival angles into physical angles. Only required if beam_type is not set to single.
:long_name = "Major angle scaling factor"
:units = "1"
float :valid_min = 0.0
float echoangle_minor_sensitivity(beam)	MA	Scaling factor to convert electrical arrival angles into physical angles. Only required if beam_type is not set to single.
:long_name = "Minor angle scaling factor"
:units = "1"
float :valid_min = 0.0
float beamwidth_receive_major(ping_time, beam)	M	One-way beam width at half power down in the horizontal direction of the receive beam.
:long_name = "Half power one-way receive beam width along major (horizontal) axis of beam"
:units = "arc_degree"
float :valid_range = 0.0, 360.0
float beamwidth_receive_minor(ping_time, beam)	M	One-way beam width at half power down in the vertical direction of the receive beam.
:long_name = "Half power one-way receive beam width along minor (vertical) axis of beam"
:units = "arc_degree"
float :valid_range = 0.0, 360.0
float beamwidth_transmit_major(ping_time, tx_beam)	MA	One-way beam width at half power down in the horizontal direction of the transmit beam.
:long_name = "Half power one-way transmit beam width along major (horizontal) axis of beam"
:units = "arc_degree"
float :valid_range = 0.0, 360.0
float beamwidth_transmit_minor(ping_time, tx_beam)	MA	One-way beam width at half power down in the vertical direction of the transmit beam.
:long_name = "Half power one-way transmit beam width along minor (vertical) axis of beam"
:units = "arc_degree"
float :valid_range = 0.0, 360.0
float rx_beam_rotation_alpha(ping_time, beam)	M	The extrinsic z-x-z clockwise rotation about the z-axis of the platform coordinate system needed to give the beam coordinate system.
:long_name = "angular rotation about the z axis"
:units = "arc_degree"
float :valid_range = −180.0, 180.0
float rx_beam_rotation_beta(ping_time, beam)	M	The extrinsic z-x-z clockwise rotation about the x-axis of the platform coordinate system needed to give the beam coordinate system.
:long_name = "angular rotation about the x axis"
:units = "arc_degree"
float :valid_range = −180.0, 180.0
float rx_beam_rotation_gamma(ping_time, beam)	M	The extrinsic z-x-z clockwise rotation about the z-axis of the platform coordinate system needed to give the beam coordinate system.
:long_name = "angular rotation about the z axis"
:units = "arc_degree"
float :valid_range = −180.0, 180.0
float tx_beam_direction_x(ping_time, tx_beam)	M	The x-axis coordinate of a unit vector in the beam direction for each tx_beam and ping, as per the sonar beam coordinate system.
:long_name = "x-component of the vector that gives the pointing direction of the tx_beam, in sonar beam coordinate system"
:units = "1"
float :valid_range = −1.0, 1.0
float tx_beam_direction_y(ping_time, tx_beam)	M	The y-axis coordinate of a unit vector in the tx_beam direction for each beam and ping, as per the sonar beam coordinate system.
:long_name = "y-component of the vector that gives the pointing direction of the tx_beam, in sonar beam coordinate system"
:units = "1"
float :valid_range = −1.0, 1.0
float tx_beam_direction_z(ping_time, tx_beam)	M	The z-axis coordinate of a unit vector in the tx_beam direction for each beam and ping, as per the sonar beam coordinate system.
:long_name = "z-component of the vector that gives the pointing direction of the tx_beam, in sonar beam coordinate system"
:units = "1"
float :valid_range = −1.0, 1.0
beam_stabilisation_t beam_stabilisation(ping_time)	M	Indicates whether or not sonar beams have been compensated for platform motion.
:long_name = "Beam stabilisation applied (or not)"
:coordinates = "ping_time platform_latitude platform_longitude"
beam_t beam_type	M	Type of split-aperture beam (or not).
:long_name = "Type of beam"
float equivalent_beam_angle(ping_time, beam)	M	Equivalent beam angle.
:long_name = "Equivalent beam angle"
:units = "sr"
float :valid_range = 0.0, 12.56637061435917295385		Maximum value is equivalent to 4π.
float gain_correction(ping_time, beam)	MA	Gain correction. This parameter is set from a calibration exercise. Necessary for type 2 conversion equation.
:long_name = "Gain correction"
:units = "dB"
short non_quantitative_processing(ping_time)	M	Settings of any processing that is applied prior to recording backscatter data that may prevent the calculation of calibrated backscatter. A value of 0 always indicates no such processing.
:flag_meanings		Space-separated list of non-quantitative processing setting words or phrases. The first item must always be the no non-quantitative processing setting and subsequent items as appropriate to the sonar and data(e.g. ”no_non_quantitative_processing simrad_noise_filter_weak simrad_noise_filter_medium simrad_noise_filter_strong”).
short :flag_values		List of unique values (e.g. 0, 1, 3, 4) that indicate different non-quantitative processing settings that could be present in the sonar data. Must have the same number of values as settings given in the flag_meanings attribute.
:long_name = "Presence or not of non-quantitative processing applied to the backscattering data (sonar specific)"
:coordinates = "ping_time platform_latitude platform_longitude"
float receiver_sensitivity(ping_time, beam)	MA	Sensitivity of the sonar receiver for the current ping. Necessary for type 2 conversion equation.
:long_name = "Receiver sensitivity"
:units = "dB re 1/μ"
float sample_interval(ping_time)	M	Time between individual samples along a beam. Common for all beams in a ping.
:long_name = "Interval between recorded raw data samples"
:units = "s"
float :valid_min = 0.0
:coordinates = "ping_time platform_latitude platform_longitude"
float sample_time_offset(ping_time, tx_beam)	M	Time offset applied to sample time-stamps and intended for applying a range correction (e.g. as caused by signal processing delays). Positive values reduce the calculated range to a sample. The range of a given sample at index sample_index and if a constant sound speed is applied is given by range= sound_speed_at_transducer(blanking_interval+sample_indexsample_interval - sample_time_offset)/2
:long_name = "Time offset that is subtracted from the timestamp of each sample"
:units = "s"
float sa_correction(ping_time, tx_beam)	MA	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
:long_name = ""
:units = ""
float blanking_interval(ping_time, beam)	M	Amount of time during reception where samples are discarded. The number of discarded sample is given by blanking_interval*sample_interval.
:long_name = "Amount of time during reception where samples are discarded"
:units = "s"
:valid_min = "0.0"
sample_t time_varied_gain(ping_time)	MA	Time-varied gain (TVG) used for each ping. Should contain TVG coefficient vectors. Necessary for type 2 conversion equations.
:long_name = "Time-varied-gain coefficients"
:units = "dB"
:coordinates = "ping_time platform_latitude platform_longitude"
float transducer_gain(ping_time, beam)	MA	Gain of the transducer beam. This is the parameter that is set from a calibration exercise. Necessary for conversion equation type 1.
:long_name = "Gain of transducer"
:units = "dB"
float transmit_bandwidth(ping_time, tx_beam)	O	Estimated bandwidth of the transmitted pulse. For CW pulses, this is a function of the pulse duration and frequency. For FM pulses, this will be close to the difference between transmit_frequency_start and transmit_frequency_stop.
:long_name = "Nominal bandwidth of transmitted pulse"
:units = "Hz"
float :valid_min = 0.0
float transmit_duration_equivalent(ping_time, tx_beam)	MA	Equivalent duration of the transmit pulse. This is the square pulse containing the same energy as the actual transmitted pulse. Necessary for both type 1 and 2 conversion equations.
:long_name = "Equivalent duration of transmitted pulse"
:units = "s"
float :valid_min = 0.0
float transmit_duration_nominal(ping_time, tx_beam)	M	Nominal duration of the transmit pulse. This is not the equivalent pulse duration.
:long_name = "Nominal duration of transmitted pulse"
:units = "s"
float :valid_min = 0.0
float transmit_frequency_start(ping_time, tx_beam)	M	Frequency at the start of the transmit pulse. The beam dimension can be omitted, in which case the value apples to all beams in the ping.
:long_name = "Start frequency in transmitted pulse"
:standard_name = "sound_frequency"
:units = "Hz"
float :valid_min = 0.0
float transmit_frequency_stop(ping_time, tx_beam)	M	Frequency at the end of the transmit pulse. The beam dimension can be omitted, in which case the value apples to all beams in the ping.
:long_name = "Stop frequency in transmitted pulse"
:standard_name = "sound_frequency"
:units = "Hz"
float :valid_min = 0.0
float transmit_power(ping_time, tx_beam)	MA	Electrical transmit power used for the ping. Necessary for type 1 conversion equations
:long_name = "Nominal transmit power"
:units = "W"
float :valid_min = 0.0
float transmit_source_level(ping_time, tx_beam)	MA	Source level generated by the transmit ping. Necessary for type 2 conversion equations.
:long_name = "Transmit source level"
:units = "dB re 1 μPa at 1m"
transmit_t transmit_type(ping_time, tx_beam)	M	Type of transmit pulse.
:long_name = "Type of transmitted pulse"
int receive_transducer_index(beam)	MA	Receiving or monostatic transducer index associated with the given beam
:valid_min = "0"
:long_name = "Receive transducer index"
int active_MRU(ping_time)	MA	Indicate the index of the MRU sensor used at the time of the ping to compute the platform attitude.
:valid_min = "0"
:long_name = "Active MRU sensor index"
:coordinates = "ping_time platform_latitude platform_longitude"
int active_position_sensor(ping_time)	MA	Indicate the index of the position sensor used at the time of the ping to compute the platform position.
:valid_min = "0"
:long_name = "Active position sensor index"
:coordinates = "ping_time platform_latitude platform_longitude"
float sound_speed_at_transducer(ping_time)	O	Sound speed at transducer depth at the time of the ping
:long_name = "Indicative sound speed at ping time and transducer depth"
:units = "m/s"
float :valid_min = 0.0
:standard_name = "speed_of_sound_in_sea_water"
:coordinates = "ping_time platform_latitude platform_longitude"
double platform_latitude(ping_time)	M	Latitude of the platform reference point in WGS-84 reference system at the time of the ping.
double :valid_range = −90.0, 90.0
:standard_name = "Platform latitude"
:units = "degrees_north"
:long_name = "latitude"
:coordinates = "ping_time platform_latitude platform_longitude"
double :_FillValue = Double.NaN
double platform_longitude(ping_time)	M	Longitude of the platform reference point in WGS-84 reference system at the time of the ping.
double :valid_range = −180.0, 180.0
:standard_name = "Platform longitude"
:units = "degrees_east"
:long_name = "longitude"
:coordinates = "ping_time platform_latitude platform_longitude"
double :_FillValue = Double.NaN
float platform_heading(ping_time)	M	Heading of the platform at time of the ping.
:standard_name = "platform_orientation"
:units = "degrees_north"
:long_name = "Platform heading(true)"
float :valid_range = 0, 360.0
:coordinates = "ping_time platform_latitude platform_longitude"
float platform_pitch(ping_time)	M	Platform pitch at the time of the ping.
:standard_name = "platform_pitch_angle"
:units = "arc_degree"
:long_name = "pitch angle"
float :valid_range = −90.0, 90.0
:coordinates = "ping_time platform_latitude platform_longitude"
float platform_roll(ping_time)	M	Platform roll at the time of the ping.
:standard_name = "platform_roll_angle"
:units = "arc_degree"
:long_name = "roll angle"
:coordinates = "ping_time platform_latitude platform_longitude"
float platform_vertical_offset(ping_time)	M	Distance from the platform reference point to the water line (distance are positives downwards). For ships and similar, this is called heave, but the concept applies equally well to underwater vehicle depth.
:long_name = "Platform vertical distance from reference point to the water line"
:units = "m"
:coordinates = "ping_time platform_latitude platform_longitude"
float tx_transducer_depth(ping_time)	O	Tx transducer depth below waterline at time of the ping (distance are positives downwards). This variable can be recomputed in most cases by applying lever arm and rotation matrix taking into account for roll and pitch, platform_vertical_offset but can also take into account for drop keel position
:long_name = "Tx transducer depth below waterline"
:units = "m"
:coordinates = "ping_time platform_latitude platform_longitude"
float waterline_to_chart_datum(ping_time)	O	Vertical translation vector at the time of the ping matching the distance from the water line to the chart data reference (typically Lowest Astronomical Tide or Mean Sea Level). This variable is the vector obtains by adding the tide, the dynamic draught at the time of the ping and allow to position samples in an absolute referential.
:long_name = "vertical translation from waterline to chart datum reference "
:units = "m"
:coordinates = "ping_time platform_latitude platform_longitude"
:vertical_coordinate_reference_system = "MSL depth"		The vertical datum to which distance are referred to. Possible values are 'MSL Depth' or 'LAT Depth'

3.10.7. Vendor specific group

The vendor specific group contains information about the sonar and data specific to the sonar. Data in this group must not be necessary for normal quantitative use of the sonar data. The contents of this group are at the discretion of the sonar and software that writes the SONAR-netCDF4 file. The netCDF4 group name is /Vendor_specific. Currently, there is no mandatory information for the vendor specific group.

4. Conversion equations

This section provides detailed formulae on how to convert the backscatter data in the Sonar group into calibrated target strength and volume backscatter strength.

4.1. Type 1

Type 1 conversion equations are used for data recorded by the Simrad SU90, SX90, and SH90 omnisonars and are presented in detail by Macaulay et al. (2016).

The complex-valued backscatter data are converted into calibrated target strength via:

\[\begin{equation} TS = 10 \log_{10}(P_{r}) + 40\log_{10}(r) + 2\alpha r - 10\log_{10}\left( \frac{P_t\lambda^{2}}{16\pi^2}\right) - G - 40\log_{10}(\cos\gamma), \end{equation}\]

where \(P_r\) is linearly proportional to the received power (square of the magnitude of the complex number given by backscatter_r and backscatter_i, W) and r is the range between the transducer and target, calculated from:

\[\begin{equation} \label{eq:timeToRange} r = \frac{c ( dt \cdot i - t_0)}{2}, \end{equation}\]

where c is sound speed (NetCDF4 variable is sound_speed_indicative, m/s), dt is the time between recorded samples (sample_interval, s), i is the sample number (from zero to one less than the number of samples), and \(t_0\) is a time-offset (sample_time_offset-blanking_interval, s).

The absorption coefficient of sound in water is α (absorption_indicative, dB/m), \(P_t\) is the transmit power (transmit_power, W), \(\lambda\) is the acoustic wavelength (derived from the average of transmit_frequency_start and transmit_frequency_stop, and sound_speed_indicative, m), G is the transducer gain (transducer_gain, dB), and \(\gamma\) is the beam tilt angle (derived from beam_direction_x, beam_direction_y, beam_direction_z, degrees from horizontal).

The volume backscatter strength (Sv, MacLennan et al. (2002)) is derived from a similar equation:

\[\begin{equation} S_{v} = 10\log_{10}(P_{r}) + 20\log_{10}(r) + 2\alpha r - 10\log_{10}\left(\frac{P_t\lambda^{2}c\psi\tau_{e}}{32\pi^{2}}\right) - G - 40\log_{10}(\cos\gamma), \end{equation}\]

where \(\psi\) is the equivalent beam angle (equivalent_beam_angle, sr), \(\tau_e\) is the effective pulse duration (transmit_duration_equivalent, s), and G is the transducer gain (transducer_gain, dB).

4.2. Type 2

Type 2 conversion equations are intended for data recorded by Furuno omnisonars. The received real-valued backscatter data are converted into calibrated target strength via:

\[\begin{equation} TS = 20\log_{10}\left(\frac{A}{\sqrt{2}}\right) + 40\log_{10}(r) + 2\alpha r - (SL + K + \Delta G + G_{T}), \end{equation}\]

where A (backscatter_r, 1) is linearly proportional to the amplitude of the received echo , r is the range as given by equation \eqref{eq:timeToRange}, and α is the absorption coefficient of sound in water (absorption_indicative, dB/m). SL is source level (transmit_source_level, dB re 1μPa at 1 m) and K is receiver sensitivity (receiver_sensitivity, dB re 1/μPa). Both parameters may depend on tilt angle of the beam for transmitting and receiving.

Gain correction, \(\Delta G\), (gain_correction, dB) is determined by the calibration. Time-varied gain, \(G_T\) (time_varied_gain, dB), is given at each sample number i.

The volume backscatter strength is derived from a similar equation:

\[\begin{equation} S_v = 20\log_{10}\left(\frac{A}{\sqrt{2}}\right) + 20\log_{10}(r) + 2\alpha r - 10\log_{10}\left( \frac{c\tau_e}{2}\Psi \right) - (SL + K + \Delta G + G_T), \end{equation}\]

where c is sound speed (sound_speed_indicative, m/s), \(\tau_e\) is the effective pulse duration (transmit_duration_equivalent, s), and \(\Psi\) is the equivalent beam angle (equivalent_beam_angle, sr). Considering the time-varied-gain (TVG) effect on the echo shape (Sawada and Furusawa, 1993), the replacement of r by \(r - r_0\), where \(r_0 = \frac{1}{4} c \tau_e\), is recommended (MacLennan, 1986; Furusawa et al., 1999) for calculation of \(S_v\).

4.3. Type 3

Type 3 conversion equations are intended for data produced by Simrad EK60, ES60, and ES70 echosounders.

The backscatter power values are stored in the backscatter_r variable with data type short (16-bit signed integers) that are converted to logarithmic received power via:

\[\begin{equation} P_r = \frac{10\log_{10}(2)}{256} P_c, \end{equation}\]

where \(P_c\) is the compressed power value stored in the backscatter_r variable and \(P_r\) the logarithmic received power that is transformed into calibrated target strength via:

\[\begin{equation} TS = P_r + 40\log_{10}(r) + 2\alpha r - 10\log_{10}\left( \frac{P_t\lambda^{2}}{16\pi^2} \right) - 2G_0, \end{equation}\]

where \(r\) is the range from the transducer to the target [m], \(\alpha\) the acoustic absorption [dB m^-1], \(P_t\) the transmitted power setting (transmit_power variable), \(\lambda\) the acoustic wavelength [m], and \(G_0\) the on-axis gain (variable transducer_gain). Volume backscatter strength is obtained from a similar equation:

\[\begin{equation} S_v = P_r + 20\log_{10}(r) + 2\alpha r - 10\log_{10}\left(\frac{P_t \lambda^2 c \psi \tau}{32 \pi^2} \right) - 2G_0 - 2S_{a,corr}, \end{equation}\]

where \(c\) is sound speed [m s^-1], \(\psi\) the equivalent beam angle (variable equivalent_beam_angle), \(\tau\) the pulse duration (variable transmit_duration_nominal), and \(S_{a,corr}\) a correction term (variable sa_correction).

The range from the transducer to the target is given by:

\[\begin{equation} \end{equation}\]

Table 12. List of equation symbols and the matching SONAR-netCDF4 variable
Symbol	Variable	Equation type
\(P_c\)	backscatter_r	all
\(\tau\)	transmit_duration_nominal	3
\(\alpha\)	Calculated from …

4.4. Type 4

Type 4 conversion equations are intended for data produced by Simrad EK80 and ES80 broadband echosounders.

5. Coordinate systems

This section provides a complete mathematical overview of the coordinate systems necessary to physically locate the position of an echo relative to a geographic coordinate system when measured from a moving or stationary platform. The coordinate systems detailed here follow those used in some multibeam bathymetric mapping sonars, but in many cases this level of preciseness will be unnecessary and several coordinate systems will overlap.

There are four right-handed Cartesian coordinate systems (Table 13, Figure 2) associated with the platform, transducer(s), and acoustic beams. Some of the coordinate systems have different origins and this is implemented as a translation vector in the input coordinate system. Rotation angles are as per the right-hand rule.

There is also a geographic coordinate system (Figure 2) that provides for location of the platform on Earth and also the height above a datum (e.g. mean sea level). The platform heading variable (degrees clockwise from north) can be used to obtain the sonar orientation in the geographic coordinate system (this applies to both stationary and mobile sonar platforms).

Table 13. List of coordinate systems used to physically locate the position of received echoes.
Coordinate system name	Origin	x-axis	y-axis	z-axis
Surface coordinate system	Platform origin	Pointing horizontally towards North	Pointing horizontally towards East	Pointing down with gravity
Platform coordinate system	Platform origin	Parallel to the main axis of the platform, positive values toward the front of the platform	Perpendicular to the main axis of the platform, positive values to the starboard side	Pointing down parallel to platform mast
Transducer coordinate system	Centre of transducer face	Pointing forward along transducer plane	Pointing starboard along transducer plane	Pointing down orthogonal to transducer plane
Sonar beam coordinate system	Centre of transducer face	Arbitrary	Orthogonal to the x-axis	Pointing along the beam axis

The platform coordinate system (PCS) is obtained from the surface coordinate system (SCS) through a rotation that corresponds to the yaw/heading, pitch and roll of the platform. No translation is necessary. Platform heave is applied in this coordinate system.

The transducer coordinate system (TCS) is obtained from the PCS through a translation of the PCS origin and a rotation to align with the transducer face. Transducer depth is applied in this coordinate system.

If a sonar actively alters beam pointing directions to compensate for motion of the platform, the beam_stabilisation variable is set to True, other False. If True, the sonar beam coordinate system (BCS) is defined by a rotation of the SCS that has been translated to the origin of the TCS. If False, the sonar beam coordinate system is obtained from a rotation of the TCS. Note that split-aperture coordinates (minor and major angles) are defined in the BCS.

Note that a coordinate in the SCS can be converted to a geographical coordinate by applying latitude and longitude to the origin.

Figure 2. Coordinate systems used to physically position an echo in an absolute geographical system. The arrows on the axes indicate the positive direction and the circular arrows around each platform coordinate system axis indicates positive rotations (Hull drawing based on image from Simrad SN90 manual, redrawn with permission).

Need to specify how the draft and heave stuff comes into the translations

Rotation of one coordinate system into another is specified via three rotations variables and can be implemented via matrix multiplication. As an example, the matrix that will convert a coordinate from coordinate system SCS to coordinate system PCS is defined by:

\[\begin{equation} M_{SCS/PCS} = M_z(h) \cdot M_y(p) \cdot M_z(r) \end{equation}\]

noting that the order of the matrices is important, and is used:

\[\begin{equation} \begin{bmatrix} x\\ y\\ z \end{bmatrix}_{PCS} = M_{SCS/PCS} \cdot \begin{bmatrix} x\\ y\\ z \end{bmatrix}_{SCS} \end{equation}\]

where \(M_z(h)\) is the rotation about the z-axis by h degrees, etc. The rotation symbols are chosen to reflect their common nautical names: h for heading, p for pitch, and r for roll and used thus:

\[\begin{eqnarray} M_x(r) = \begin{bmatrix} 1 & 0 & 0 \\ 0 & \cos(r) & -\sin(r) \\ 0 & \sin(r) & \cos(r) \end{bmatrix} \\ M_y(p) = \begin{bmatrix} \cos(p) & 0 & \sin(p) \\ 0 & 1 & 0 \\ -\sin(p) & 0 & cos(p) \end{bmatrix} \\ M_z(h) = \begin{bmatrix} \cos(h) & -\sin(h) & 0 \\ \sin(h) & \cos(h) & 0 \\ 0 & 0 & 1 \end{bmatrix} \end{eqnarray}\]

To be clear, the right-hand rule when applied to roll, pitch, and heave means that:

looking along the positive x-axis, a positive rotation (roll) is clockwise (to starboard),
looking along the positive y-axis, a positive rotation (pitch) is clockwise (bow up),
looking along the positive z-axis, a positive rotation (yaw) is clockwise (to starboard).

The orientation of the platform is represented using the z–y’–x” Tait-Bryan intrinsic rotation convention (en.wikipedia.org/wiki/Euler_angles), corresponding to yaw, pitch, and roll, respectively. Intrinsic means that rotations about the y-axis are measured after any rotation about the z-axis, and rotations about the x-axis are measured after rotations about the y-axis (for comparison, extrinsic angles are applied relative to a fixed-platform orientation). This is the most used rotation convention in the maritime field, and the main effect is that roll is measured relative to the plane tilted by the pitch angle.

Several coordinate system offsets can be given in the Platform group. These allow for precise specification of the origin of sensors, such as the position and attitude sensors, and sonar transducer. The offset is a (x,y,z) tuple in the platform coordinate system. Offsets are to be interpreted as a vector that starts at the platform coordinate system origin and ends at the sensor position. For example, an offset of (1, 2, –3) indicates a position that is 1 m toward the bow, 2 m to starboard, and 3 m above the origin of the platform coordinate system.

Some sensors (e.g. the attitude sensor) can have a rotation relative to the platform-coordinate system. This is represented as the extrinsic rotation required from the platform coordinate system’s x-, y-, and z-axes to arrive at the sensor’s x-, y-, and z-axes.

5.1. Split-aperture coordinates

Some sonar beams can estimate the arrival angle of echoes (Chapter 6). These angles are given as minor and major angles in the sonar beam coordinate system (Figure 3):

The z-axis is always the beam axis with the origin at the receive transducer,
The minor arrival angle (\(\phi\)) is given by the angle from the z axis, measured in the x-z plane, and
The major arrival angle (\(\theta\)) is given by the angle from the z axis measured in the y-z plane.

Positive minor angles occur in the positive x plane and positive major angles occur in the positive y plane.

For conventional downward-looking echosounders mounted on a ship it is normal that the sonar beam coordinate system is identical to the transducer coordinate system and hence the split-aperture minor angle is oriented alongships with positive angles towards the bow and the split-aperture major angle is oriented athwartships with positive angles to starboard.

Figure 3. The split-aperture minor and major angles in the sonar beam coordinate system.

5.2. Equations for positioning echoes in a geographical coordinate system

5.2.1. Beams are stabilised by the sonar and beam pointing angles are relative to SCS

5.2.2. Beams are not stabilised by the sonar and beam pointing angles are relative to TCS

6. Split-aperture beams

Some sonar beams can estimate the arrival angle of echoes using the split-aperture method and SONAR-netCDF4 supports several ways to store such angles. The type of split-aperture beam data contained in a SONAR-netCDF4 file is given by the beam_type variable in each Beam_groupX subgroup. Split-aperture echo arrival angles are always given in the sonar beam coordinate system (see Chapter 5).

When sub-beams from a split-aperture transducer are provided, it is also necessary to combine them to give the power or amplitude of the echoes, as received by the combined beam. All known split-aperture systems achieve this by taking the average of the sub-beam values, noting that the sub-beam data are typically complex power or amplitude values.

To allow for existing conventions on how the split-aperture angles are stored or derived (typically as phase angles between the split-aperture signals), angle sensitivities are given in variables echoangle_major_sensitivity and echoangle_minor_sensitivity.

6.1. Angles stored in file

The calculation of the echo arrival angle is done by the sonar and the SONAR-netCDF4 file contains either physical arrival angles or phase angles. For the latter, the major (\(\theta\)) and minor (\(\phi\)) physical arrival angles are obtained by dividing by the major \(\eta_\theta\) and minor \(\eta_\phi\) angle sensitivities respectively. For consistency, when physical arrival angles are stored in the file, \(\eta_\theta\) and \(\eta_\phi\) should still be present and be set to 1.0.

6.2. Angles not stored in file

The sonar does not calculate the echo arrival angle - they are calculated from the split-aperture sub-beams, each of which are stored in the SONAR-netCDF4 files. Several types of sub-beam arrangements are supported (Figure 4) - the angle calculation methods for each type are given in the following sections. The sub-beams are stored as the subbeam dimension in the backscatter variables in Table 11, in the same order as labelled in Figure 4.

Figure 4. The split-aperture transducer arrangements supported by SONAR-netCDF4 (A: 4 quadrants; B: 3 sub-beams; C; 3+1 sub-beams). The Cartesian coordinates show the orientation of the sonar beam coordinate system relative to the transducer sub-beams (note that the z'-axis points into the page). The numbers indicate the sub-beam labels for each type of transducer.

6.2.1. Four quadrants (type A)

This arrangement has four equal quadrants in the transducer (Figure 4, part A) and the major (\(\theta\)) and minor (\(\phi\)) angles are calculated thus:

\[\begin{equation} \theta = \frac{\arctan \left( \Im((y_2+y_3)^*), \Re(y_1+y_4) \right)}{\eta_\theta}\\ \phi = \frac{\arctan \left( \Im((y_1+y_2)^*), \Re(y_3+y_4) \right)}{\eta_\phi} \end{equation}\]

where \(\arctan\) is the four-quadrant inverse tangent, \(y_x\) the complex signal from quadrant \(x\), * indicates the complex conjugate and \(\Re\) and \(\Im\) the real and imaginary parts of the complex numbered signals. The angle sensitivities are \(\eta_\theta\) for the major axis and \(\eta_\phi\) for the minor axis.

6.2.2. Three or four sub-beams (type B and C)

This arrangement has either three equal sub-beams (Figure 4, partB) or a centre sub-beam and three surrounding sub-beams. (Figure 4, part C). Type C can be treated the same as type B once the centre sub-beam signal is added to each of the outer sub-beam signals. The phase angles between two pairs of the three sub-beams are then given by (Bodholt, 2001; Bjørnø, 2017):

\[\begin{equation} \omega_{31} = \arctan \left( \Im((y_3+y_1)^*), \Re(y_3+y_1) \right) \\ \omega_{32} = \arctan \left( \Im((y_3+y_2)^*), \Re(y_3+y_1) \right) \end{equation}\]

where \(\arctan\) is the four-quadrant inverse tangent, \(y_x\) the complex signal from quadrant \(x\), * indicates the complex conjugate and \(\Re\) and \(\Im\) the real and imaginary parts of the complex numbered signals. The major (\(\theta\)) and minor (\(\phi\)) angles are then:

\[\begin{equation} \theta = \frac{1}{\sqrt{3}\eta_\theta} (\omega_{31} + \omega_{32})\\ \phi = \frac{1}{\eta_\phi} (\omega_{32} - \omega_{31})\\ \end{equation}\]

where \(\eta_\theta\) is the angle sensitivity for the major axis and \(\eta_\phi\) the angle sensitivity for the minor axis.

7. Revision history

Document version	SONAR-netCDF4 version	Date	Changes
1.8	1.0
1.7	1.0	29 May 2018	Modifications due to ICES CRR review and editorial process.
1.6	1.0	7 Feburary 2018	Modifications due to further Topic Group input.
1.5	1.0	20 December 2017	Formatted to ICES CRR style
1.4	1.0	18 September 2017	Added additional CF attributes to time variables. From Topic Group input: incorporation of Type 2 equation and additional variables to support it. Consistency and clarity corrections.
1.3	1.0	21 June 2017	Extensive and significant modifications derived from feedback on v1.2, from creation of test SONAR-HDF4 files, and from implementation of reading in LSSS.
1.2	1.0	2 February 2017	Further modifications after internal review.
1.1	1.0	13 January 2017	Modifications after generation of test datasets.
1.0	1.0	22 December 2016	Draft version for distribution to ICES WGFAST Topic Group on “Defining a data format for omni fisheries sonar”.

8. Acknowledgements

We are grateful for the thorough and considered contributions from the Marine Acoustics Society of Japan’s Technical Committee. Advice and experience on the practicalities of reading netCDF files in analysis software was generously provided by Christian Michelsen Research AS, Echoview Software, and Nortek AS. Sindre Vatnehol and Arne Johannes Holmin kindly developed software to generate SONAR-netCDF4 files. We also thank Elodie Fernandez and Jim Biard for their invaluable reviews and suggestions for improving both the convention and this document.

9. References

Bjørnø, L. 2017. Applied Underwater Acoustics. Elsevier.

Bodholt, H. 2001. Split-Beam Transducer with 3 Sections. In Proceedings of the 24th Scandinavian Symposium on Physical Acoustics, pp. 32–39. Ustaoset, Norway.

Eaton, B., Gregory, J., Drach, B., Taylor, K., Hankin, S., Blower, J., Caron, J., et al. 2017. NetCDF Climate and Forecast (CF) Metadata Conventions, Version 1.7.

Furusawa, M., Hamada, M., and Aoyama, C. 1999. Near Range Errors in Sound Scattering Measurements of Fish. Fisheries Science, 65: 109–116.

Gee, L., Doucet, M., Parker, D., Weber, T., and Beaudoin, J. 2012. Is Multibeam Water Column Data Really Worth the Disk Space? In Conference Proceedings of Hydro12, pp. 81–86. Hydrographic Society Benelux, Rotterdam, The Netherlands.

ICES. 2016. A Metadata Convention for Processed Acoustic Data from Active Acoustic Systems. SISP 4 TG-AcMeta Version 1.10, ICES WGFAST Topic Group, TG-AcMeta.

ISO. 2014. ISO 19115-1. Geographic Information - Metadata - Part 1:Fundamentals. International Standard.

Jackson, M. A., Groeber, M. A., Uchic, M. D., Rowenhorst, D. J., and Graef, M. D. 2014. H5ebsd: An Archival Data Format for Electron Back-Scatter Diffraction Data Sets. Integrating Materials and Manufacturing Innovation, 3: 1–12.

Macaulay, G. J., Vatnehol, S., Gammelsæter, O. B., Peña, H., and Ona, E. 2016. Practical Calibration of Ship-Mounted Omni-Directional Fisheries Sonars. Methods in Oceanography, 17: 206–220.

MacLennan, D. N. 1986. Time Varied Gain Functions for Pulsed Sonars. Journal of Sound and Vibration, 110: 511–522.

MacLennan, D. N., Fernandes, P., and Dalen, J. 2002. A Consistent Approach to Definitions and Symbols in Fisheries Acoustics. ICES Journal of Marine Science, 59: 365–369.

McQuinn, I. H., Reid, D. G., Berger, L., Diner, N., Heatley, D., Higginbottom, I., Andersen, L. N., et al. 2005. Description of the ICES HAC Standard Data Exchange Format, Version 1.60. ICES Cooperative Research Report No. 278.

Sawada, K., and Furusawa, M. 1993. Precision Calibration of Echo Sounder by Integration of Standard Sphere Echoes. Journal of the Acoustical Society of Japan, 14: 243–249.

The HDF Group. 2017. Hierarchical Data Format, Version 5. http://www.hdfgroup.org/HDF5.

Triton. 2013. Triton Imaging, Inc. eXtended Triton Format (XTF) Revision 35.

UCAR. 2014. UDUNITS. http://www.unidata.ucar.edu/software/udunits.

Unidata. 2017. Network Common Data Form (netCDF) Version 4. UCAR/Unidata.

Annex 1: Working with netCDF4 files

NetCDF4 files are not commonly used for fisheries acoustics data. To facilitate the use of such files, this section provides simple examples of how to access and use SONAR-netCDF4 files in commonly used programming languages, namely Python, R, and Matlab.

Python example

# Import packages needed to read and view data from netcdf4
from netCDF4 import Dataset
import numpy as np
import matplotlib.pyplot as plt

# Name of the netcdf file
filename = 'SU90-D20171107-T195023.nc'

# Open the file
dataset = Dataset(filename)

# Open the group where the backscatter data is located
SonarGr = dataset.groups['Sonar'].groups['Beam_group2']

# Get the backscatter data from the 10th ping and and 31st beam
back_r = SonarGr.variables['backscatter_r'][9,30]
back_i = SonarGr.variables['backscatter_i'][9,30]

# Close dataset
dataset.close()

# Compute the power
power = abs(np.vectorize(complex)(back_r,back_i))**2

# Plot the power of beam
plt.figure(1)
plt.clf()
plt.plot(10*np.log10(power))
plt.xlabel('Sample number')
plt.ylabel('Amplitude [dB]')

R example

library(h5)
SU90_nc <- PATH_TO_SONAR_NETCDF4_FILE

# The h5 package is able to read the example file:
data <- h5file(SU90_nc)

# Show the contents:
data

# List the dimensions of the data sets:
ds <- list.datasets(data)
dims <- lapply(ds, function(x) openDataSet(data, x)@dim)
names(dims) <- ds
dims

# Note that the backscatter data are stored as variable 
# length datatype, so the dimensions in 'dims' does not 
# reflect to the full size of the backscatter data. 
# In this particular file the length of all beams and all 
# pings of both Beam_group1 and Beam_group2 are identical:

bs_r1_name <- "/Sonar/Beam_group2/backscatter_r"
bs_i1_name <- "/Sonar/Beam_group2/backscatter_i"

# Save the real part and set dimension to 
# [length of beams, number of beams, number of pings]:
backscatter1 <- complex(
real=unlist(data[bs_r1_name][10,31]), 
imaginary=unlist(data[bs_i1_name][10,31]))
power <- abs(backscatter1)^2

# Plot the first and second beam of the third ping:
plot(10*log10(power), type="l", 
ylab="Power", xlab="Sample number")

# Close the file:
h5close(data)

Matlab example

% Example Matlab script to load a SONAR-netCDF4 file using the
% high-level HDF5 functions.

% File to read
file = 'SU90-D20171107-T195023.nc';

% Ping and beam to read
pingNo = 10;
beamNo = 31;

% Read the selected ping/beam from the file
amp_r = h5read(file, '/Sonar/Beam_group2/backscatter_r', [beamNo pingNo], [1 1]);
amp_i = h5read(file, '/Sonar/Beam_group2/backscatter_i', [beamNo pingNo], [1 1]);

% Calculate the power values for the ping.
power = abs(complex(cell2mat(amp_r), cell2mat(amp_i))).^2;

% Plot the power
plot(10*log10(power))
xlabel('Sample number')
ylabel('Power (dB)')

Annex 2: Contact information

Editors
Gavin John Macaulay Institute of Marine Research, Norway gavin.macaulay@hi.no	Héctor Peña Institute of Marine Research, Norway hector.pena@hi.no
Members of the Topic Group on Defining a data format for omnidirectional fisheries sonar (part of ICES Working Group on Fisheries Acoustics, Science, and Technology)
Akira Okunishi Furuno Electric Co. Ltd., Japan akira.okunishi@furuno.co.jp	Christophe Cobieres iXblue SAS, France christophe.corbieres@ixblue.com
Arne Johannes Holmin Institute of Marine Research, Norway ArneJohannes.Holmin@hi.no	Dezhang Chu National Oceanic and Atmospheric Administration, USA dezhang.chu@noaa.gov
Atle Totland Institute of Marine Research, Norway atle.totland@hi.no	Doug McGowen Edgetech, USA Doug.McGowen@edgetech.com
Benoit Berges Wageningen Marine Research, The Netherlands benoit.berges@wur.nl	Gavin John Macaulay Institute of Marine Research, Norway gavin.macaulay@hi.no
Briony Hutton Echoview Software, Australia briony.hutton@echoview.com	Glen Rice National Oceanic and Atmospheric Administration, USA glen.rice@noaa.gov
Héctor Peña Institute of Marine Research, Norway hector.pena@hi.no	Leon Smith Faroe Marine Research Institute, Faroe Islands leonsmit@hav.fo
Inge Christian Eliassen Christian Michelsen Research Institute, Norway inge.eliassen@cmr.no	Mariano Gutiérrez Agroceánica Consultores, Perú msgtorero@gmail.com
Jan Arge Jacobsen Faroe Marine Research Institute, Faroe Islands janarge@hav.fo	Nils Olav Handegard Institute of Marine Research, Norway nilsolav@hi.no
Kouichi Sawada Japan Fisheries Research Agency, Japan ksawada@fra.affrc.go.jp	Sindre Vatnehol Institute of Marine Research, Norway sindre.vatnehol@hi.no
Koshi Haraguchi Sonic Corporation, Japan koshi-haraguchi@u-sonic.co.jp	Stéphane Gauthier Fisheries and Oceans Canada, Canada stephane.gauthier@dfo-mpo.gc.ca

Editors

Gavin John Macaulay

Institute of Marine Research, Norway

gavin.macaulay@hi.no

Héctor Peña

Institute of Marine Research, Norway

hector.pena@hi.no

Members of the Topic Group on Defining a data format for omnidirectional fisheries sonar (part of ICES Working Group on Fisheries Acoustics, Science, and Technology)

Akira Okunishi

Furuno Electric Co. Ltd., Japan

akira.okunishi@furuno.co.jp

Christophe Cobieres

iXblue SAS, France

christophe.corbieres@ixblue.com

Arne Johannes Holmin

Institute of Marine Research, Norway

ArneJohannes.Holmin@hi.no

Dezhang Chu

National Oceanic and Atmospheric Administration, USA

dezhang.chu@noaa.gov